It is common today for a business or similar entity to utilize a voice response unit (VRU) in conjunction with a communication system and host information processor system in order to automate responses to client requests for services or information. Typically, a VRU is implemented at a business location as a subsystem interacting with the business'telephone communication system, such as a private branch exchange (PBX), and data processing systems.
The VRU subsystem itself is a processor-based system requiring an operating algorithm, or application, in order to interact with the PBX and data processing host, such as a LAN, according to the entity's desires in response to the user's inputs or data queries. This algorithm is a set of instructions presenting a user interface, or user dialogue, in the form of a call flow.
Typically, the user dialogue is but one component of a VRU application. Presently, to generate this one component, it is not uncommon for a developer to utilize some form of high level scripting tool to define a dialogue presenting the caller's choices, soliciting responses, and data input from callers. The dialogue may also provide for accessing other attached systems to retrieve information or perform some other functions, such as a call completion on behalf of the caller. Additionally, the dialogue may provide for the user to modify or customize the environment by allowing the input of certain parameters, such as a number of voice mailboxes desired, a length of message to record, etcetera.
However, operation of the VRU subsystem to present a desired call dialogue requires manipulation and interaction of a complex set of data elements including: system configuration options, such as system wide and user specific configuration options; system user or subscriber preferences and information; system access information, such as security or feature accessibility; etcetera. These data elements must both be initialized as well as be accessed from time to time, such as from a support system, in order to be maintained
In present systems, data element initialization and maintenance functions are handled as a separate, and very discrete, programming function. For instance, a VRU application that maintains a data base for a set of subscribers, including user preferences, home phone numbers, cellular phone numbers, office phone numbers, etc., typically also includes a set of parameters that describe from a system level (application level) how the application should behave or operate, setting for instance the number of maximum mail boxes per user and algorithms for determining what messages should be forwarded to which mail boxes, etc.
All of the data elements used by the call dialogue must be initialized (create a data fill) upon deployment of the VRU application. Thereafter, the database storing the data elements may be runtime accessed by the VRU application to control the behavior of the application or to provide the data elements required for operation of the application.
Currently, providing user interfaces for database maintenance functions requires a second step of using a database programming language in order to build a separate set of interfaces for the database. Through these interfaces, typically in the form of user interactive input screens, an administrator or user may access the data elements to vary them or initialize them for a particular subscriber.
A problem encountered in present implementations is that changing the VRU application and/or adding new data elements requires a separate discrete programming effort to update the user interfaces to reflect changes in the data elements. Therefore, there is a real problem in synchronization of these user interfaces as changes and modifications are made to the application and/or its data elements. Maintaining this synchronization presently requires a considerable amount of time and effort in order to keep current these data maintenance screens.
Another problem with present implementations is the provision and modification of data element parameters such as data security level, data fill information, or what user has what type of access to a particular data element. For example, there may be a data element, such as the number of mail boxes or the length of a mail box in a voice mail application, which is initially modifiable by a system administrator. If the restriction were to be modified to enable the data element to be user modifiable, on a user by user basis, to be able to change the data element dynamically and to allow for all possible security levels and access methods to that data, a large number of screens would need to be built or modified. As a result, even where the data sets have been varied only slightly with the characteristics of that data, a significant amount of synchronization, and thus parallel programming, is required of present implementations.
A need therefore exists in the art for a system and method for providing data set definitions from information provided to an application creation tool.
A need also exists in the art for a system and method which generates user interfaces suitable for manipulating fill data associated with data sets utilized by an application creation tool.
A further need in the art exists for a system and method for modifying data set definitions when an associated application is modified.
A still further need in the art exists for a system and method for creating and/or modifying user interfaces suitable for manipulating fill data associated with the data sets of a service application as modified.
A need in the art also exists for a system and method providing initial fill data to initialize data sets associated with an application generated by an application creation tool.